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ABSTRACT 

The intelligent Maintenance Training System (IHTS) is 
a set of software tools that permit the composition and presentation 
of interactive graphical simulations for computer-based technical 
training. IHTS is designed to support training on the operation and 
maintenance of complex devices. Simulations are authored by device 
experts, who use the IHTS tools to draw the components of the device 
to describe their behavior, and to create simulations made up of the 
components. IHTS provides special support for maintenance training. 
An artificial expert on troubleshooting strategy, called "Profile," 
generates instruction and advice for students. RAPIDS is an 
additional set of tools, built on the foundation of IHTS, that 
enables the authoring of a wide variety of simulation-based training 
courses. Using RAPIDS, an expert creates lessons by performing in the 
simulation tasks that are to be taught to students. This technical 
report includes: (1) an overview of IHTS; (2) a description of the 
development and applications of derivative simulations; (3) a 
discussion of nurfaoe simulation authoring; and (4) a description of 
the use of RAPIDS to author instruction. An illustrated catalogue of 
simulations developed using IHTS is appended. (14 references) 
(Author/GL) 
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ABSTRACT 

The Intelligent Maintenance Training System (IMTS) is a set of 
software tools that permits the composition and presentation of 
interactive graphical simulations for computer-based technical 
training. IMTS is designed to support training on the operation and 
maintenance of coiiplex devices. Simulations are authored by device 
experts, who use the IMTS tools to draw the components of the 
device to describe their behavior, and to create simulations made up 
of the components. 

IMTS provides special support for maintenance training. An 
artificial expert on troubleshooting strategy, called Profile, generates 
instruction and advice for students. 

RAPIDS is an additional set of tools, built on the foundation of IMTS, 
that enables the authoring of a wide variety of simulation-based 
training courses. Using RAPIDS, an expert creates lessons by 
performing in the simulation the tasks that are to be taught to 
students. 
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Introduction 

The exploitation of interactive graphical simulation for computer-based instruction has 
been limited by the time and expense typically associated with the production of 
complex simulations. The Intelligent Maintenance Training System (IMTS) provides an 
environment for the composition and presentation of such simulations. The authoring 
environment permits the construction of simulations based on either of two quite 
different approaches. In one, which is component-oriented, model-based simulations 
are composed by direct manipulation. In the other, simulations based on the behavior of 
an equipment system as a whole are built up by creating tables of data that describe that 
behavior. The former approach is called deep simulation; the latter, surface simulation. 

The model-based, generative approach (deep simulation) has two advantages over a 
table;look-up style of simulation. First, it permits more robust simulations, which 
provide nearly complete free-play features. Second, object-oriented models can be 
developed relatively rapidly since the developer does not have to describe behaviors of 
the total system. To employ the model-based approach, an author must understand the 
fu: :tions of the objects in the simulated system. An author who understands a complex 
system only in terms of the behaviors of the system in various operating modes would 
have difficulty following the component-oriented model-based approach. 

Overview of IIUITS 

IMTS provides editors for composing both deep and surface interactive graphical 
simulations for training without using computer programming. It also includes a 
generic expert that can generate instruction in the domain of fault diagnosis. The 
resulting simulations are presented in an environment that permits students to directly 
manipulate graphical controls and to observe the effects of these manipulations on 
simulated indicators and test points. 

IMTS attacks two productivity problems for the authoring of simulation-based 
training: (1) the development of flexible and accurate simulations at reasonable cost, 
and (2) the authoring of expertise about the model domain. 



The Student Interface 

IMTS simulations may depict the simulated device or system in a variety of different 
ways, including schematically and in a front-panel format. Large simulations are 
divided into mulUple graphic simulation scenes, each of which depicts some portion of 
the whole device. Students can navigate through the scenes 1) by bringing up a 
hierarchical map of all the scenes and selecting the one they wish to view, or 2) by 
selecting special scene icons that act as doorways to odier scenes. 

The studen. manipulates some of simulated object by use of the mouse. When the 
object, such as a switch, changes state in response to the student, it correspondingly 
changes its appearance, and it usually causes other objects to change their states. In 
addition to manipulating controls and observing simulated front panel indicators and 
mtemal actions of objects, students can examine values at object ports using simulated 
test equipment When they work with large simulations, students sometimes discover 
behaviors of wmch even the authors were not aware. 



The figure below shows the entire IMTS screen during student use. 
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The largest window displays any one scene in the simulation. The scene shown depicts a 
portion of a helicopter blade-folding system. At this time the IMTS is explaining, in the 
left-hand text window, how an expert would have approached a just-completed 
problem. Also, the student had made copies of three objects from other scenes, and 
placed them in the upper scratch-pad area. These duplicate copies are manipulable and 
graphically dynamic, J ist as are the originals from die other scenes. 



Generation of Domain Expertise 

In contrast with the use of conventional expert systems methodology, IMTS does not 
require the authoring of expertise about troubleshooting a particular device. Instead, a 
generic troubleshooting expert, called Profile (Towne, 1984, 1986; Towne & Johnson, 
1987), is applied to data generated from the simulation model to produce evaluations of 
student actions, recommendations and other advice, and normative or expert 
solutions. Profile's use of simulation-generated data is an examole of an approach we 
have sought to apply wherever possible in IMTS: to exploit the model data and the 
simulation as fully as possible to generate instruction rather than requiring expensive 
authoring steps. 

During practice problems, the Profile model in IMTS evaluates the student's diagnostic 
performance, and it offers assistance in conducting an efficient and rational diagnostic 
process. Both of these support functions rely on Profile's ability to compute near- 
optimal testing decisions at each stage of a problem. Profile's generic strategy is to find, 
at each step, the test that offers the potential for revealing the most new information 
about the status of the system relative to the-cost of obtaining the information. These are 
a function of the symptoms produced by all failures under consideration, the cost and 
reliability of each replaceable unit, and the time to replace each unit 

By maintaining a concurrent and internal evaluation of tiie symptoms seen by the 
student, Profile is able to evaluate each student action and to comment on it s usefulness. 
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Profile can also generate advice tailored to tiie user's personal progress in working on 
this problem. The advice given takes into account what the student could have learned 
about the troubleshooting problem from the tests he or she conducted, the reliability of 
each element in a device, and the time to perform alter. ative tests and replacements. 
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When a student has finished a troubleshooting problem, EMTS can use Profile to present 
a step-by-step critique of the student s work. In a similar format, it can generate and 
explain an expert (Profile) approach to the problem, as shown below. 
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The Student Model and Problem Selection 

IMTS maintains information about the student during the course of a training session. 
This mformation constitutes a simple model of the student. Three types of data about 
the student are maintained: 

• A unitary measure of competence in the domain 

• An estimate of preferred problem step size 

• An overlay model of knowledge about the domain 

The overlay model of student knowledge is a set of weights on the nodes of a knowledge 
tree that represents normative knowledge about the device that constitutes the domain 
of mstruction. The normative knowledge model is constructed using the IMTS 
knowledge editor. 
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For each node in the knowledge tree, authors enter a number that represents an estimate 
of how well the average student understands the concepts it represents when they first 
begm working with the simulation. These estimates are called deiault mastery values 
for the knowledge nodes. When a new student begins working with an IMTS 
simulauon. a copy of these mastery values is generated. This is the individual student 
model. These mastery values are altered in response to a student's performance, so a 
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student's entire set of values represents the IMTS estimate of the student's knowledge 
based on performance. 

At the end of each problem, a mastery value is computed for the problem node. This 
value is based on the correctaess of the problem solution, the number of errors made en 
route to the solution, and normalized time to solution. It is an estimate of the student's 
mastery of the knowledge requiied to tioubleshoot the malfunction. 

Mastery values are propagated upward in the tree. The immediate parent node of the 
pioblem node is modified by an amount that is proportional to the number of its 
children. This modified mast^ value for the component node is, in turn, propagated 
to its parent, and so on. The solution of a single problem results in a small change even 
to the root node, which represents knowledge about the device as a whole. 

To make an automatic problem selection, IMTS computes the conceptual distance from 
the last problem node to each of the available (not yet done) nodes. Conceptual distance 
trom a node is the sum of the weighted links on the path between the nodes. The weights 
used are the inverse of the mastery values on the nodes in the paths. The automatic 
problem selector attempts to pick a problem with a conceptual distance that is congruent 
with the student's preferred problem step size. In addition, the problem selected should 
have a difficulty level that is congruent with the present estimate of the student's 
competence in the domain. These two factors — problem step size congruence and 
difficulty/competence congruence are heuristically combined to select an appropriate 
problem. 



Deep Simulation 

The deep simulation approach is preferred to the surface approach whenever the author 
has a thorough understanding of the behavior of the components of the simulated 
device. Deep simulations do not require the detailed authoring of effects at the device 
level that are required for the construction of surface simulations. 

Behavior Modeled at the Element Level 

The objects used in IMTS simuladons can be produced by non-programmers, and they 
can be saved and used in any number of specific applications. This contrasts with some 
other approaches to simulation composition, such as that employed in STEAMER 
(Williams, HoUan, & Stevens, 1981; HoUan, 1983; HoUan & Hutchins, 1984) in which 
the simulated device is modelled with a specially written computer program. 
(STEAMER'S graphical indicators — such as gauges and indicator lights — are generic 
elements that can be used at different points in a simulation, or in different simulations.) 
The IMTS approach has the advantage of permitting faster and easier simulation 
development, for the class of systems that can be simulated in this manner. The 
STEAMER approach has the advantage that it can simulate virtually any system, but at 
considerably higher cost. 
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advantage to constructing the simulation of predefined objects is that models 
of failed components also can be created and inserted into the simulation. This failure 
insertion can be done by the student, to observe and learn about effects; it can be done 
by the instructional routines in IMTS, to set up an instructive diagnostic problem; or it 
can be done by the simulator if a cunrent mode and/or failure condition causes a new 



Local Propagation of Effect 

Every generic object has a set of behavior rules for each of its states. One rule 
determines when the object will transition to the state. Other rules, called performance 
effects, determine the values of the ports of the object in that state. Ports are points on 
an object that are associated with the passing of values to and from other objects. In 
terms of the represented world, ports are electrical, hydraulic, or mechanical 
connections. 



When a student changes the state of a simulated control object, the object's performance 
etfect rules determine new values for some or all of its output ports. These values an; 
passed on to the neighboring objects, some of which may change state as a result of their 
new input values. These objects will, in turn, pass values on to the objects to which they 
are connected. In a complex simulation, hundreds of objects may be affected by a single 
manipulation, and thousands of port values may be recomputed. 

Cbmplex system-level behaviors are derived from simpler component-level behaviors. 
This permits accurate free-play simulations without requiring authoring an immense 
number of combinatorial effects (as did some earlier simulation training systems 
developed by this research group, described in Towne, 1986; Towne & Munro. 1981- 
and Towne, Munro, Johnson & Lahey, 1983). 

A major advantage of generating system behaviors from the detailed functional model 
IS that the author is not concerned with where or when abnormal symptoms will appear 
in the simulated system; the effects are computed according to both connectivity and 
Object behavior. Thus, symptoms produced by a failed part might not show up until the 
signal reaches a particularly sensitive indicator. It might then appear normal for a 
nuniber of tests (which perhaps cannot discriminate the abnormality), followed by 
further abnormal symptoms. . 

The Deep Simulation Algorithm 

The sirnulation update is triggered when the state of an object, such as a switch, is 
changed. One possible effect of a state change is that an output value changes. For 
example, a variable voltage source would produce different values at its output port 
depending on the setting ot the object. In this case, the port, with its new value, is put on 
a source stack. Another possible effect of a state change is that the path through the 
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object may be altered. For example, a valve could be changed fram Straight to Crossed. 
In this case, each port on an altered path is put on the source stauk. 

The simulation driver continues running as long as there is anything on the source 
stack. It works by removing one item (port) from the stack and starting the propagation 
of that port's value through the system. Each port record stores the port's value and its 
connection to another object's port The valu<; of the Arst port is passed to the second 
port The object containing the second port then computes what to do, given that new 
input value. 

When a new value reaches an object one of three things can happeu: 

(1) The object may serve as a dead end; the new value doesn't 
affect the state of the object and there is no path through the 
object that Includes the input port This terminates a segment of 
the simulation. For example, when the valve s'iOwn at the right is 

^ in the state depicted, its port A is a dead end for values 
propagated to it 

(2) The value can be passed to an output port of the object Possibly the value will be 
changed when it passes through the object as in a pressuie reducer; usually the value is 
unchanged, as in a valve, a pipe, or a wire. When the value is passed through the object 
v; is handed to the port of the cor.nected object 

V?) The value can cause an object to change state. However, the state is not changed 
immediately. Instead, when it is determined that an object should change state, it is put 
on a "change state" stack. This stack is necessitated by die fact that an object's state may 
depend upon two (or more) port values; when the first value anives (is computed), it 
and the old second value may dictate that the object change, but v/hen the new second 
value anives, a different result may be called for. Perhaps the object shouldn't change 
at ail, or perhaps it should change to a different state from what was initially indicated. 
Consequently, no states are changed until the source stack is empty and there is no 
further propagation of values. At that point, an object is taken from the change state 
stack. If the in^'dal instruction to change has been countermanded, then no state change 
is produced. If object does change state, that will often retrigger a simulation update, 
since the change will usually result in one or more ports being put on the source stack. 

The simulation update finally ends when there is nothing on the source stack, there is 
nothing on the change state stack, and no values are being propagated. 

A Simple Simulation 

A simulation is composed of instances of generic objects. Below is a simple simulation 
of a Rube Goldberg machine that uses electrical, hydraulic, and mechanical compv nents 
to turn a light on and off. Power Supply A provides power through a sv/itch to an 
electrically operated control valve, ^vhile Power Supply B provides power to the 
Output Light if the Actuator is extended. 




When the user moves the Main Power Switch to the right, the valve is put in its crossed 
position, as shown below. This directs hydraulic pressure to the mechanical Actuator 
(at the right in the diagram), causing it to extend. The actuator pushes a contact closed, 
and electrical power turns on the Output Light 
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If a user moves the switch to the left, the valve goes into its straight state, as shown 
below, and the actuator is retracted. The contact below opens, and the Output Light 
goes out All these responses are produced in accord with the behavior rules stored with 
each generic object 
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The Bladefold Simulation 

The largest deep simulation constructed thus far with IMTS is the Bladefold simulation 
1 ms is a thirteen-scene simulation with hundreds of specific objects. It simulates the 
blade fold/spread/brake mechanism of a military helicopter. The figure below displays 
one of the thuteen Bladefold scenes. 
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The Bladefold system uses a complex combination of electrical, mechanical, and 
hydraulic parts, and it is not functionally modular. A change in one component may 
have an effect on many other active components distributed throughout the system. In 
the deep simulation, therefore, a student's manipulation of a switch may result in the 
activations of hundreds of other objects. Despite this complexity, performance of the 
simulation is quite acceptable. A worst-case time to completely simulate a response to a 
student acdon is approximately 14 seconds, which is about half as long as the real-world 
device response. Many graphical effects are displayed during this process, so the 
student is actively engaged. For a more thorough description of the Bladefold 
Simulation, see Appendix O and F of IMTS User's Manual (1989). 

Scene Composition 

EMTS simulations are composed from libraries of generic objects. As the object 
instances are positioned in the diagram, any input/output ports close to ports on adjacent 
objects are automatically noted as being connected, and can therefore exchange values. 

When an individual scene of the functional model is completed the author may interact 
with it to verify its behaviors. The scene editor provides tools for setting input values 
manually, so that a scene can function independently. When all the individual scenes 
have been verified, the author connects them by identifying the port connections that 
cross scene boundaries. 
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Generk Object Authoring 

New simulations may require some object types not available in any library of generic 
objects. )u these cases, authors can add new generic objects to their libraries. There are 
two major steps to building ^ new generic object First, each of the different ways that 
the object oan appear is drawn on the screen. Second, the behaviors for the generic 
object are specified in terms of the conditions under which each state exists and the 
resulting effects produced by the object under each condition. The effects are expressed 
as values at output ports of the object as a function of values at input ports of the object 
Thus each object is specified entirely in terms of its local environment 
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Graphic Construction 

(The input/output tables A and B 
appear only in authoring mode.) 



State 1 Result: 5 <- 


A 


Failure: None 




Condition: A > 5 




Failure: Stuck On 




Condition: None 




State 2 Result: B <- 


0 


Failure: None 




Condition: A <» 5 




Failure: Stuck Off 




Condition: None 





Rule Definition 

A simple example is shown above. The object being added to the library, called a 5- 
filter, goes mto an ON state (state 1 ) if its input at Port A is greater than 5 or if the part 
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has failed in a stuck-ON condition. In this state the output at port B will be the same 
value that is input at port A. If the input is less than or equal to 5, or if the part has failed 
Stuck-OFF, then the object is in the OFF state (state 2)» and it outputs zsto. With these 
behavior rules, both normal and malfunctioning situations are simulated. 

Producing Fault-effect Data 

Like a human troubleshooter, Profile must consider the possible effects of a vast array 
of failures. While the IMTS simulation reflects the effects of the current failure(s), 
Ptofile requires access to failure-effect information for all the possible failures. To 
minimize the compute time to generate die fault effect data, the author identifies the 
failures that could cause each of the complaints that will be used to start problems. A 
complaint is a verbal statement that states some abnormality that has been observed by 
an operator, such as "The signal to noise ratio is low in FCK Transmit mode" The 
author then executes a special batch program that automatically inserts each possible 
failure into the simulated device in each mode of interest, it executes the simulation to 
determine the effects of the fault, and it records the fault's effects. This process is 
illustrated betow. 
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The resulting table of fault effect data allows Profile to rapidly search for powerful 
next tests, to evaluate the power of the student's test selections, and to determine and 
explain the significance of test result obtained by the student, as he or she interacts with 
the IMTS simulation. Profile conducts its analysis by maintaining a set of suspicion 
levels for possible ro<» If unctions. Initial suspicion levels are determined from the 
inherent reliabilities of the parts of the device. These could be modified over time to 
reflect field experience with a particular device. As students perform tests in IMTS, 
Profile modifies the current suspicion levels to reflect the inferences that could be 
drawn from the results. 



Development and Applications of 
Derivative Simulations 

For many devices a complete IMTS simulation will be too complicated to be used 
introductory students. IMTS p wides a mechanism for creating simplified simulatior.s 
der:ved from the detailed functional model. These simplified simulations operate 
correcfly, even though some or many of their critical parts axe not shown, because the 
parts that are shown obtain their behaviors from their counterparts in the complete 
tunctional model. This allows the simplified models to appear to operate correctly, 
even though they could not really operate in the real-world without the missing parts. 

The IMTS authoring feature that supports these derivative simulations is called yoking. 
One object can be yoked to another, meaning that the behavior of the yoked object will 
be determined, not by the behavior rules of its own generic type, but rather by the 
behavior of the specific object to which it is yoked. 

Yoking can also be used to rapidly create physical representations of systems. These 
representations may be appropriate for training device operation as well as fault 
diagnosis using front panel indicators. In the figure on the next page, a detailed 
funcuonal model has been developed from the IMTS Generic Object Library. Then a 
threeHSlemeat scene was produced by yoking SI, S2, and the indicator light to their 
schematic counterparts m the Detailed Functional Model (the detailed IMTS simulation 
model). If a student sets SI on the from panel view, the indicator light on the front panel 
view will come on because SI was automatically set in the functional model, and the 
indicator light there was determined to be in the ON state. 

When IMTS simulations are used to support training in equipment operation, this more 
physical form is usually desired, although the underiying schematic form may be a 
powerful explanatory tool. / * a 
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Surface Simulations 



Surface simulations are developed by explicitly specifying behaviors of objects in 
relation to other objects in the particular device. Authors use the surface simulation 
methodology for devices that are too complex to describe in terms of the independent 
behaviors of their components. 



Previous Surface Simulation Systems 



The surface sunulation methodology in IMTS is closely akin to that used in some earlier 
training systems developed at Behavioral Technology Laboratories. The technique 

STJrS ^ ^^P^®'' ^y^*®" behaviors in terms of specific conditions 

rather than by enumerating the countless combinations of switch settings and failure 
s^tes. The conditions express the settings of switches and the existence or absence of 



While the surface simulation approach is considerably less robust than the deep 
f~ ! ^"^^ ^ simulate systems whose inner workings 

^nH ? Tw ^"""Z "n^^fstood by the simulation developer or are too complicated lo 
i^^. .1 A n * 'ec^n^cian having extensive field experience with a system could 
produce a fuUy accurate surface simulation by working out all the various effects of 
from panel configurauons and malfunctions on indicators and test points, even though 
that individual might not fully understand the functions of the individual uidts 

The past limitations of surface simulation have been significantly overcome in IMTS. 
ppIS-°*- Generalized Maintenance Training System (GMTS) and 

dev^'Z^'r^T:^^^ P?^"'^^ ^® medium employed to simulate the 

St thp ' ""^f""? was randomly retrievable color microfiche images, for 

EEMT the medium was videodisc. While the videodisc version retrieved and displayed 
images quickly and reliably, it suffered from the same limitation as the microfiche 
S^iS phonographic images were required of every system state in 

fc^f^ornL^ni ir^T °^ of switch settings and indicator readings was 

!^?h tV^ only recourse m these earlier systems was to minimize the contents of 
each scene. Thus a typical scene might contain four to six switehes and a few indicators, 
and would require between sixty to two hundred different photographs to reflect all the 
different combinations of object states. Not only was the time and cost to produce these 

S l^^yTf opposition ?o the deSred 

goal of realistically simulating the real device. 

In IMTS, the graphic representation of each object is produced independently, thus 

Si"" ^ ^ ^^^Pi^y accommodate, and the viewer of a 

simulation cannot detect whether it was produced using surface or deep techniques 



The second limitation to earlier surface simulations was that they embraced no 
instructional or diagnostic expertise. The instructional and diagnostic functions in 
IMTS operate for surface simulations as well as deep simulations. The difference here 
is that the fault-effect information for surface simalations must be supplied by a human 
expert, whereas it is generated automatically for deep simulations. 

Overview of Surface Simulation Authoring 

A surface simulation author constructs scenes c^r graphical objects that are yoked to the 
surface objects. These graphical objects get their appearances from libraries of generic 
objects, jus£ as do the objects of deep simulations. Their behaviors, however, are not 
based on the behavior deflnitions in a library. Instead, their behaviors that is, their 
changes in appearance — are driven by current state data associated with surface object 
data records to which they are yoked. 




Four editors are used to define surface simulation behaviors. The Surface Object Editor 
creates specific objects that have certain data associated with them, such as their names 
and types. These specific objects need not be associated with any graphical objects. The 
MoJe Editor is used to define equipment modes of interest in terms of the states of 
specific objects. The Test Editor defines tests, which are indicators and/or test points 
viewed in particular modes. The Surface Matrix Editor is used to declare what values a 
test should exhibit in various failure conditions. 

Surface Object Data 

For every switch, indicator, jumper, or other replaceable object in a device, the author 
enters a data record describing that object These data records are called surjface objects 
in IMTS. The behavior of a surface simulation is determined by these data records and 
by others that describe the important modes of the device and tests that can be 
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performed in those modes. Surface objects, per se, do not have appearances; they are 
only bundles of data, including the following attributes: 

• Name 

• Hidden status (the default is False) 

• Initial state (set at run time for test points & indicators) 

• MTBF.cost, (for Profile diagnostic guidance) 
replacement time 

• Description (used for discussing with the student) 

• Video scene (the name of the video scene on which the object appears) 
' Default Value 

The surface object editor , shown below, is used to enter such data for a simulation. 
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Modes and Tests 



Authors define the modes of a surface simulation. A mode is a combination of object 
states of interest. For example, the power switch being set to on is a simple mode of 
mterest A more complex mode is power on and standby off and number 1 engine 
switch set to start. Mode information is edited with the mode editor. 



Mod^ name: M^asur^Cha • j 


Modes 


(Power-Switch Power-On) 
(Channel -Switch Channel -2} 
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MeasureChS 
MeasureMlxed 
PowerOff 




PowerOn 



A surface matrix editor is used to specify how indicators and test points behave based on 
the defined modes in a number of malfunction states. For each mode that is relevant for 
an indicator, the value or state of die indicator is specified for each malfunction. 



^ 








Pov/arLlg 
htOn 


Ldve 








9velMixo 






Normal Value 
LessZero 










Zeto 




Sumod'Ou 


oil 


N 


EightyPive 
SeventyFlve 


NIL 




Off 


Nl 


Ten 
GreaterThlOO 


NIL 


Failed-Ope 






■ 






Normal 


On 




T«n 





This fault-effect matrix is identical to that used for deep simulation. The only 
difference is that in surface simulations the symptom data must be supplied by a human 
ext)ert. 

During a simulation, when the student changes a switch, all the modes that refer to that 
switch check to see whether their truth has changed. Certain modes may become true as 
a result of the switch manipulation. For each mode that changes, all of the indicators 
that refer to that mode are updated. If an indicator's state changes, then the graphic 
object that represents that indicator is redisplayed in the new state. 

The WSC-3 Simulation 

The largest surface simulation constructed thus far with IMTS is the AN/WSC-3 
Simulation. The AN/WSC-3 is a satellite communication system used for voice and data 
communication. The WSC simulation, comprised of twenty-eight scenes, demonstrates 
the surface simulation capabilities of IMTS. The figure below shows die top-level scene 
of the system. 
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A WSC'3 Simulation Scene 



Most of the graphic objects in tlie top-level scene are icons that lead to more detailed 
views. When the student clicks on the Front Panel unit, for example, IMTS displays a 
close-up view, showing the cunent switch settings. 

While videodisc is not a convenient medium with which to represent panels of 
equipments in each of the possible modes, it is quite attractive as a means to display test 
equipment readings. When the student performs an oscilloscope reading on the WSC-3, 
he or she sees the waveform as a photographic image retrieved from the videodisc. 

Creating Profile Data for Surface Simulations 

After defining the normal behavior of a surface simulation using the test editor, the 
author prescribes how the device behaves in various malfunction states. The surface 
matrix editor is used to describe the behavior of the simulated device under a given 
complaint. A complaint is a statement of abnormal behavior that applies to a number of 
related failures. The matrix below specifies the behavior of the WSC-3 system for the 
malfunctions that prevent normal transmission. 
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In suxfacc simulations this table of data supports the simulation as well as supplying 
Profile with, the necessary symptom information. 



Authoring Instruction by Direct lUanipulation 

Until recently the instructional applications of IMTS have been limited to intelligent 
support of practice in fault diagnosis. Because IMTS generates all instructive 
interactions, it cannot offer explicit instruction in such topics as theory of operation, 
front panel configurations, symptom identification, or test interpretation (although 
IMTS practice involves these skill components). 

RAPiDS (Rapid Prototype ITS Development System) was developed to provide 
additional features for authoring and delivering instructional interactions, based on 
IMTS simulations. Using the RAPIDS tools, authors can create instructional units on 
almost any device-related topic, largely by performing the procedures that they want 
their students to learn on the simulation. RAPIDS is extensively described in Towne & 
Munro (1989) and in Munro & Towne (1989). 
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After creating an IMTS simulation, authors can build domain-specific content units, 
using a content unit editor. These content units ai'e organized into an instructional plan 
using an instructional organization editor. Authoring is direct and largely error-free 
because it is built on the foundation of an IMTS simulation. 




Instructional Content Authoring 

RAPIDS instruction is created by operaUng a live IMTS simulation, and by adding text 
and ^phics to highlight and explain the procedures and effects being demonstrated. 
Thcfigure below shows the RAPIDS content editor being used to create instruction for 
an aircraft engine stirtiag system (adapted from Kieras, 1988). 
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Authoring Content Units 

A content unit is authorei^ by performing operations on the simulation and by creating 
instructive expositions, before and/or after each action, that explain and elaborate on 
what the expert is doing and how the device is responding. The action might change the 
state of the simulated device, such as setting a switch or replacing a (simulated) 
defective part It might reveal something about the state of the simulated device, such as 
making a test reading using simulated test equipment. Or, it might be a simple 
identiHcation of some object or area in the simulation graphics, or a response on a 
multiple-choice list 



The expositions can highlight portions of the simulation display, they can play videodisc 
frames, they can display text, and they can control waiting for various events or time 
durations. The text in expositions may be presented in a standard text window at the side 
of the simulation graphics or it may be positioned on the graphic simulation to relate 
closely to particular parts of the device representation. The author has the option of 
setting the simulated device into a particular mode of operation prior to the unit. 
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Typically, the unit is first played for the student in an instruct mode. Each of the 
author's actions are automatically performed along with the accompanying text and/or 
videodisc expositions. In this mode the student simply studies the simulated actions, the 
device responses, and the accompanying explanations, and paces the presentation 
according to his or her own learning speed. Then the unit can be presented in drill 
mode. As in instruct mode, the learner sees the instructive expositions, but now 
attempts to perform all the actions and selections. All errors are automatically 
corrected by RAPIDS. 

Depending upon the course plan, the same unit presented in instruct and drill mode may 
also be presented in test mode. In this mode the learner does not see the instructive 
expositions, and attempts to perform die procedures and drills unaided. Throughout the 
presentations, RAPIDS automatically monitors -nd remediates the learner, and it 
maintains performance scores for each learner on each unit. 

Student Actions 

The specification of a student action may be any of the following: 

• selecting or identifying one or more objects or areas on the simulation 

• manipulating one or more switches into speciHed states 

• replacing a simulated object 

• peribrming a specified test using simulated test equipment 

• making one or more selections from a menu of text items 

The last of these options provides sl mechanism for specifying multiple choice questions 
and answers. A simple user interface provides a straightforward implementation that 
does not require any special authoring techniques. 

Expositions 

An exposition may consists of a combination of the follov/ng exposition elements types: 

• presenting text in the message window or a floating window 

• clearing the message window 

• playing a videodisc segment 

• highlighting an object or region in the simulation window 

• unhighlighting an object or region in the simulation window 

• changing the scene displayed 

• waiting for a student response 

• waiting for a specified amount of time 

Automatic Interactions with Students 

The built-in functions in RAPIDS automatically generate many standard student 
interactions. These include providing informative feedback on errors, giving help on 
request, evaluating performance, and repeating content units as required. 
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In the 5guze below, a learner was unable to locate the Air Diverter Valve. RAPIDS 
attempted to resolve the confusion by informing the learner what he had mistakenly 
taken for the Air Diverter Valve. After t^vo errors, RAPIDS showed the learner the 
correct answer. 




Instructional Organization 

RAPIDS provides an interactive tool for creating and editing instructional plans for 
courses. The instructional plan specifies what content units will be presented, in what 
mode (instruct, drill, test) they will be presented, and under what conditions they will 
be presented to individual students. The plan also specifies how much time can be 
devoted to the various units, how many times a unit may be repeated, and what speed 
and accuracy scores are required to complete a unit 

The window below shows a plan for a simple course about an engine starter system. 
Plans are organized as tree structures of blocks. The terminal blocks, shown in dashed 
lines, are content units that are individually produced using the content unit editor 
described above. The blocks shown in solid lines are called organizational units. These 



are simply groups of other units. The course editor is used to add, delete, and move 
units, and to specify the manner in which the units will be delivered to the learner. 
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pe instructional plan shown above organizes the course into three major topics. 
Students will first learn about the device organization, then be introduced to operations, 
and finally be drilled on operations. These three topics are each structured as 
organizational units. The unit covering Device Organization consists of two content 
units, each of which includes some subject matter to be delivered, whereas the other two 
m^or topics consist of further sub-topics, or organizational units. 

pe window below the tree window displays data about the currently selected unit. The 
data can be edited in this window. In this example, the organizational unit called 
Operation Drill' has been selected! The parameters shown with each sub-topic specify 
the manner in whici • the unit will be irsJructed. 



Structure of Instructional Plan Units 

An organizational unit lists other units to be presented. The member units may be 
content units or other organizational units. Associated with each unit in a course plan 
are these data fields: 

• weight: the importance of the called unit (relative to the others in the 

list) 

• mode: whether to execute a called content unit in Instruct, Drill, or 

Test mode 

• condition: an optional expression that controls whetiier to present the 

unit to a learner 
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• maxunum: the maximum number of times to present the unit 

• minimum: the minimum number of times to present the unit 

• limit: the time limit for the unit, in minutes 

• accuracy: the accuracy score (%) required to complete the content unit 

successfully 

• speed: the speed score required to complete the content unit 

successfully, in minutes 

RAPIDS automatically computes a composite accuracy score at all levels of the 
instructional plan. The weight parameter listed above is used to compute this figure. 
RAPIDS al^-o maintains spe^d scores for all units, reflecting the time spent by each 
learner at each level. 

The condition parameter is an option that specifies the conditions under which a unit 
will be presented. The condition can be any expression in terms of the performance of 
the learner on any unit, the time spent in various units of instruction, and the number of 
repetitions of units by the learner. 

Thus a single instructional plan can deliver quite different courses to different learners 
depending upon the performance of each. The course content, time devoted to topics, 
repetitions of topics, and degree and type of remediation are all tailored by RAPIDS to 
meet the high-level specifications of the course plan while recognizing the details of 
individual student performance. 

Summary 

The tools in IMTS and RAPIDS provide twelve different modules for constructing 
simulation based instruction of one type or another, and three interactive instructional 
delivery programs. The author uses die menu shown below to select and execute the 
module to be used. The first column contains the two key editors for building graphical 
simulations, the Generic (object) Editor, and the Scene Editor. The former of these is 
run to add new objects to die Object Library. After creating one or more scenes with 
the Scene Editor, the author selects Build Simulation, which compiles the newly 
constructed simulation scenes for execution. The simulation may then be started by 
selecting Run Simulation from the menu. 



25 



Simulation 


SurfaetModti Piagnortic Training RAPIDS 


Gtntric Editor 


Objtd Editor 


Otap Matrix Editor 


Plan Editor 


Sctnt Editor 


Modt Editor 


Problam Editor 


Conttnt Editor 


Build Simulation 


Ttit Editor 


Run IMTS 


Run RAmS 


Run Simuladon 


Matrix Editor 








Vidto Editor 







Alternatively, surface simulations are constructed using the five editors listed in the 
second column. These editors accept information about surface objects, eauipment 
modes, tests, fault effect data, and videodisc frame numbers. 

Two editors are used to produce the fault effect data needed to support diagnostic 
training for a simulation, as listed in the third column. The Deep Matrix Editor accepts 
specification of modes and failures and then executes the batch program that generates 
the fault effect data required by Profile, The Problem Editor accepts problem 
specifications (failed objects and failure modes) and associated verbal statements 
(complaints) that are presented at die start of each troubleshooting problem. After 
^iKtxn^mW^S^ a simulation can be run in the IMTS intelligent training mode by 

After cieating a simulation, RAPIDS courses are built using the two editors listed in the 
fourth column. The author uses the Plan Editor to construct and modify the 
instructional plan, and the Content Editor to perform and explain tasks on the 
simulation. Typically, an author would construct a simulation using the editors in either 
the first or second column (deep or surface), then use the RAPIDS tools to create a 
comp ete course. The diagnostic training functions would be utilized only if IMTS 
(Profile-guided) diagnostic problems are also to be presented. 

Conclusions 

IMTS was developed to bring together and apply a number of diverse and experimental 
techniques in intelligem tutoring. The two most fundamental concepts diat influenced 
me design were 1) the use of a responsive, object-oriented graphical model that could 
be manipulated by a learner, as pioneered in the STEAMER project, and 2) the 

generic models of diagnostic and 

instructional expertise. 

In addition to the two major applications developed under contract, several dozen small 
applications have been created by others in two workshops conducted at BTL The 
P^fiiJ^P?"^, ^*^®se workshops were provided three days of training in producing 
lMi5 simulations, and then devoted one to two days developing small applications 
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These test applications revealed numerous areas where either the authoring facilities or 
the user documentation could be improved or corrected. All errors were corrected, and 
wherever possible, features that simplified the authoring cask were implemented. 
Screen images I^Dom many of these projects are included in the appendix to this report 

The workshop participants included technical subject matter experts and instructional 
researchers, having computer programming skills ranging from none to proficient. 
Their performance indicated that developers with a relatively wide range of skills could 
become productive IMTS users fairly quickly, and that they could apply the system 
effectively. Finally, the range of simulations that were produced provided a good 
indication of the generality of the techniques. 

Latest Developments 

The most recent worie on IMTS, as described in this report, was conducted 1) to expand 
the applicability of the technique to a considerably wider range of devices; 2) to provide 
tools needed by a much broader conununity of instructional developers; and 3) to 
produce instruction for a much broader range of proficiency levels. 

Extended Device Applicability 

The incorporation of the surface-level simulation technique into IMTS provides 
developers a way to utilize the resources of IMTS even when the device to be instructed 
cannot be reasonably represented at the object level. While the basic surface level 
simulation approach employed in IMTS is very similar to that used in earlier systems 
(GMTS, EEMT, and ESAS), the ease of development is vastly improved in IMTS, 
owing to the ability to specify and depict objects individually rather than collectively. 
Thus the development of economical high-resolution computer graphics has had 
profound impact on the internal representations of devices as well as their external 
manifestations. 

The simulation of the WSC-3 Satellite Communications System was produced in a very 
short time, owing primarily to the previous experience of the two subject matter 
experts involved. One of these had extensive experience operating and maintaining the 
WSC-3 system; the other had previously produced a GMTS ilata base for it. While this 
application therefore does not provide a representative test of development effort, it 
does indicate the speed with which a surface simulation is produced, given that the 
subject matter knowledge is extensive. 

Extended Range of Instructional Resources and Strategies 

The demonstrated instructive potential of IMTS attracted numerous potential 
developers who wished to utilize the tools, but who wanted to apply different or more 
varied instructional strategies and scenarios than those built in to IMTS. The interactive 
authoring facilities developed in RAPIDS allows diagnostic training to go beyond the 



27 

*^ : ■ 



four scenarios of initial IMTS (practice problems, expert demonstration, problem 
debrieHng, and free exploration). 

Using RAPIDS, one can develop drills for familiarizing students with terminology and 
topology, exercises in associating symptoms with possible causes, and instructional 
units presenting theoiy of operation and troubleshooting. Beyond diagnosis, RAPIDS 
can be used to develop courses in device operation, preventative maintenance, or safety 
procedures. Moreover, the course developer can control allocation of time and the 
cntena for meeting instructional objectives. 

Extended Range of Learners 

The original IMTS is an effective tool for sharpening the diagnostic skills of 
mtennediate to expert troubleshooters on a particular device. Having absorbed much of 
me theory of operation via conventional lectures, such technical students can gain much 
from working practice problems with IMTS support The entering student, however, 
could not realistically attempt even the easier problems in a device as complex as 
Bladefold because the IMTS representation of the device was necessarily complete. 
While a developer might be able to produce simpler models for the novice student, 
doing so would necessarily entail producing many new and artificial objects, whose 
behaviors are also simplified, just for the purpose of supporting simpler 
representations. *^ 

The derived simulation capabilities described in this report allow developers to produce 
a series of successively more complex and complete representations of a device. Thus 
simple models of complex systems function as tiiey should even tiiough critical parts are 
absent from the simplified representation. Now IMTS can be applied in a manner that is 
consistent with the instructional philosophy of White and Frederiksen (1987), a 
philosophy of successive model elaboration to which we heartily subscribe. 

The derived simulation features also allow development of device representations that 
are physically realistic, tiiereby providing an appropriate interface with which to 
practice device operation and other procedures, as well as use of front panels for 
diagnostic functions. 

Maintaining Cognitive Fidelity 

While our goals have included allowing the learner to experience simpler worlds 
before more complex ones, we have also attempted to maintain those cognitive aspects 
of fault diagnosis tiiat lie at the heart of this difficult process, whatever the difficulty of 
tiie problem being presented. Consequently IMTS provides the learner with practice in 
performing tests as well as selecting them, in interpreting tests as well as observing 
them, and in making inferences about possible causes that require understanding 
component behavior as well as system structure. With the addition of the RAPIDS 
authoring features, part-task drills can be developed that instruct separable cognitive 
skills in equipment operation as well as diagnosis. 
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Appendix: Simulations Developed Using IMTS 



Two quite large simulations have been developed in IMTS, as described in the text of the report. 
In addition, a number of simpler simulations have been developed by attendees at IMTS training 
seminars. Many of these simulations were developed in one or two days, following one or two 
days of lectures and demonstrations. 




if ^ Simulation: SH-3H Helicopter blade folding systtjm 

J^.- Number of Scenes: 13 

I Authors: Quentin PizzinI and David Surmon (University of Southern California) with Bill Johnson (Search Technology) 

V 

- ^^fi' 



tut,. 



Appendix — Simulations Developed Using IMTS 



^^iiiX^ul^t'ion Window 



MAINPOW6R 
ON 



OFF 



O MAIN BLADE FOLD O 



BUVOES 
SPREAD 



FLIGHT 
PCS 



o o 

N0.1 GONTUOCK 
BLADE P08 PINS AOV 

o o 



FOLD PWR 




SPREAD 



BLADES 
FOLDED 



PYLON 



O O 



SAFETY 
VALVE 

O 



UNLOCKED 



OPEN 



o 



J 




8»h»viop»l T»chno!coy L*J»cp*ter1»» 



SImulatJon: SH-SH Helicopter blade folding system - 14th scene 
Number of Scenes: 1 
Authors: Vem Malec and Mike Cowan (Navy Personnel Research and Development Center). 

(This fourteenth scene was added to the original thirteen to provide an improved 'front oanel' interface thp 
scene was produced by yoking its objects to objec is in the original deep simulaS^onT 
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Simulation: WSC-3 Satellite communication system 
Number of Scenes: 25 

Author: Lee Coller (University of Soutiiern California); data provided by Ron Renfro (Mantech Mathetics). 
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Simulation: Internal combustion engine 
Number of Scenes: 1 

Authors: Russ Hunt and William Johnson (Search Technology) 
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Appendix-— Simulations Developed Using IMTS 
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Simulation: Munition Hoist 
Number of Scenes: 1 
Author William Murray (FMC) 
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Appendix '■'Simulations Developed Using IMTS 
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Simulation: F-1 5 Manual Avionics Test Station 
Number of Scenes: 1 
Author: Marilyn Bunzo (Learning Research and Development Center. University of Pittsburgh) 



. Append — Simulations Developed Using IMTS 



Oif^plav Window 




Simulation: M16 Trigger Assembly 
Number of Scenes: 1 

Author: Randy Morten (Air Force Human Resources Laboratory) 
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Simulation: Jot onglne oil cooling system 
Number of Scones: 1 

Author: Quentin PIzzlnl, David Surmon, Douglas M. Towne, and Allen Munro. 
Adapted from: 

Keskey. L. C. & Sykes. D. J. Expert systems in aircraft maintenance 'raining. In Proceedings of the IEEE Weste> 
Co/Jterenca. Anaheim, CA: 1987. ^ 
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Simulation: Fuel System 

Number of Scenes: 1 

Authors: Mike Gick (Texas Instruments) 
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Simulation: CS Aileron Trim System 
Number of Scenes: 2 

Authors: Bob Elm and Tom Holzman (Locl<heed Georgia) 
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Simulation: Spoiler 
Number of Scenes: 1 

Authors: Tom Holzman and Bob Elm (Lockheed Georgia) 
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